incremental models！（文件）

簡單來說就是從原本的 create or replace table 變成 insert into table，在這樣轉變的過程中，優勢是，我們可以只更新新進來的資料，不需要去重新運算已經處理過的資料。

這個操作我們過去使用 BigQuery procedures 時也有使用。

然而這個做法其實也有蠻多麻煩之處的，首先它的寫法與原先的整張表重新建立不同，需要重新編寫。
或是譬如在增減欄位或調整運算邏輯後，需要重新處理整張表格。
還有要如何確保只抓到未更新過的資料。

dbt 的 incremental models 提供我們一個方法，透過 config 與 macro 的設定，我們可以用同樣的 sql code，僅加上一些參數的設定，就讓這些資料表，若是不存在時，自動以建立資料表的方式處理，當有資料時，可以根據資料更新狀態，將未更新的資料新增進資料表中。

講到這邊，可能會覺得為什麼要做這麼複雜，直接砍掉重練多輕鬆呢。

錢啊！還得是錢！處理越多資料就越貴、也越花時間，一切都是為了省時省力省錢（好像沒有省到力？）

dbt 算是有幫忙到以事半功倍的方法做到這件事。

一張資料表，主要是 fact table（因為只有它適合以時間來做切片），必須在運算時省到錢，有兩個情況：

1. 在建立這張表，改成使用 insert 的方式加入資料，上游只讀取更新部分的資料，而必須做到這件事情，就必須使用 partition功能（BigQuery 文件），將資料以 ingestion time 或是 created time 來去做每小時、每日或每月的切分。
   我們的日更資料表原先要讀取數年的資料，現在變成只要讀取這兩天新進來的資料，省下大把的運算成本！
2. 這張表被下游使用時，只讀取部分區間的資料，譬如說規定下游在進行視覺化時，盡可能只使用特定區間的資料，可能是這個月、或這個學期等。

這兩個情況，通常第一點會節省的幅度較大，因為原始資料的量體應該遠大於轉換後的資料表，而要省到這筆成本，必須將上游的原始資料 (source) 做 partition。這塊可能就要看資料 ingestion 的方式了，我們正好有跟軟體協作，針對比較大的事實表格，改以每日新增資料的方式處理，將資料以新增的日期來做切分；另外也正在進行將實時串流資料以 ingestion time 的日期做切分，可以滿足這一個條件。

第二點有時候也很實用，尤其當資料表會被高頻率讀取時，像我之前處理的服務中，有每幾分鐘就要讀取資料的情況，有 partition 就幫了大忙；或是在多數不特定人常常使用的公開資料的情境中，也很有幫助。

總結來說，如果上游資料表沒有 partition，下游也沒有很頻繁的取用資料的話，或是這張資料表轉換完畢後，量級已經比原始資料小很多的話，做成 incremental model 就沒有這麼大的意義了。